Optimierung des Dispatch von WebGL Compute Shadern: Abstimmung der Workgroup-Größe

Compute Shader, ein leistungsstarkes Merkmal von WebGL, ermöglichen es Entwicklern, die massive Parallelität der GPU für allgemeine Berechnungen (GPGPU) direkt in einem Webbrowser zu nutzen. Dies eröffnet Möglichkeiten zur Beschleunigung einer breiten Palette von Aufgaben, von Bildverarbeitung und Physiksimulationen bis hin zu Datenanalyse und maschinellem Lernen. Das Erreichen optimaler Leistung mit Compute Shadern hängt jedoch vom Verständnis und der sorgfältigen Abstimmung der Arbeitsgruppengröße ab, einem entscheidenden Parameter, der vorgibt, wie die Berechnung auf der GPU aufgeteilt und ausgeführt wird.

Grundlagen: Compute Shader und Arbeitsgruppen

Bevor wir uns mit Optimierungstechniken befassen, wollen wir ein klares Verständnis der Grundlagen schaffen:

• Compute Shader: Dies sind Programme, die in GLSL (OpenGL Shading Language) geschrieben sind und direkt auf der GPU laufen. Im Gegensatz zu herkömmlichen Vertex- oder Fragment-Shadern sind Compute Shader nicht an die Rendering-Pipeline gebunden und können beliebige Berechnungen durchführen.
• Dispatch: Der Vorgang des Startens eines Compute Shaders wird als Dispatching bezeichnet. Die Funktion gl.dispatchCompute(x, y, z) gibt die Gesamtzahl der Arbeitsgruppen an, die den Shader ausführen werden. Diese drei Argumente definieren die Dimensionen des Dispatch-Gitters.
• Arbeitsgruppe (Workgroup): Eine Arbeitsgruppe ist eine Sammlung von Arbeitselementen (auch als Threads bezeichnet), die gleichzeitig auf einer einzigen Verarbeitungseinheit innerhalb der GPU ausgeführt werden. Arbeitsgruppen bieten einen Mechanismus zum Teilen von Daten und zur Synchronisierung von Operationen innerhalb der Gruppe.
• Arbeitselement (Work Item): Eine einzelne Ausführungsinstanz des Compute Shaders innerhalb einer Arbeitsgruppe. Jedes Arbeitselement hat eine eindeutige ID innerhalb seiner Arbeitsgruppe, die über die integrierte GLSL-Variable gl_LocalInvocationID zugänglich ist.
• Globale Aufruf-ID (Global Invocation ID): Der eindeutige Bezeichner für jedes Arbeitselement über den gesamten Dispatch hinweg. Sie ist die Kombination aus der gl_GlobalInvocationID (Gesamt-ID) und der gl_LocalInvocationID (ID innerhalb der Arbeitsgruppe).

Die Beziehung zwischen diesen Konzepten lässt sich wie folgt zusammenfassen: Ein Dispatch startet ein Gitter von Arbeitsgruppen, und jede Arbeitsgruppe besteht aus mehreren Arbeitselementen. Der Code des Compute Shaders definiert die von jedem Arbeitselement durchgeführten Operationen, und die GPU führt diese Operationen parallel aus, wobei sie die Leistung ihrer mehreren Prozessorkerne nutzt.

Beispiel: Stellen Sie sich vor, Sie verarbeiten ein großes Bild mit einem Compute Shader, um einen Filter anzuwenden. Sie könnten das Bild in Kacheln unterteilen, wobei jede Kachel einer Arbeitsgruppe entspricht. Innerhalb jeder Arbeitsgruppe könnten einzelne Arbeitselemente einzelne Pixel innerhalb der Kachel verarbeiten. Die gl_LocalInvocationID würde dann die Position des Pixels innerhalb der Kachel darstellen, während die Dispatch-Größe die Anzahl der verarbeiteten Kacheln (Arbeitsgruppen) bestimmt.

Die Bedeutung der Abstimmung der Arbeitsgruppengröße

Die Wahl der Arbeitsgruppengröße hat einen tiefgreifenden Einfluss auf die Leistung Ihrer Compute Shader. Eine falsch konfigurierte Arbeitsgruppengröße kann zu Folgendem führen:

• Suboptimale GPU-Auslastung: Wenn die Arbeitsgruppengröße zu klein ist, werden die Verarbeitungseinheiten der GPU möglicherweise nicht voll ausgelastet, was zu einer geringeren Gesamtleistung führt.
• Erhöhter Overhead: Extrem große Arbeitsgruppen können durch erhöhte Ressourcenkonflikte und Synchronisationskosten einen Overhead verursachen.
• Speicherzugriffs-Engpässe: Ineffiziente Speicherzugriffsmuster innerhalb einer Arbeitsgruppe können zu Engpässen beim Speicherzugriff führen und die Berechnung verlangsamen.
• Leistungsschwankungen: Die Leistung kann bei verschiedenen GPUs und Treibern erheblich variieren, wenn die Arbeitsgruppengröße nicht sorgfältig gewählt wird.

Das Finden der optimalen Arbeitsgruppengröße ist daher entscheidend für die Maximierung der Leistung Ihrer WebGL Compute Shader. Diese optimale Größe ist hardware- und arbeitslastabhängig und erfordert daher Experimente.

Faktoren, die die Arbeitsgruppengröße beeinflussen

Mehrere Faktoren beeinflussen die optimale Arbeitsgruppengröße für einen gegebenen Compute Shader:

• GPU-Architektur: Verschiedene GPUs haben unterschiedliche Architekturen, einschließlich variierender Anzahlen von Verarbeitungseinheiten, Speicherbandbreite und Cache-Größen. Die optimale Arbeitsgruppengröße unterscheidet sich oft zwischen verschiedenen GPU-Herstellern (z.B. AMD, NVIDIA, Intel) und Modellen.
• Shader-Komplexität: Die Komplexität des Compute-Shader-Codes selbst kann die optimale Arbeitsgruppengröße beeinflussen. Komplexere Shader können von größeren Arbeitsgruppen profitieren, um die Speicherlatenz besser zu verbergen.
• Speicherzugriffsmuster: Die Art und Weise, wie der Compute Shader auf den Speicher zugreift, spielt eine wichtige Rolle. Gebündelte Speicherzugriffsmuster (wobei Arbeitselemente innerhalb einer Arbeitsgruppe auf zusammenhängende Speicherorte zugreifen) führen im Allgemeinen zu einer besseren Leistung.
• Datenabhängigkeiten: Wenn Arbeitselemente innerhalb einer Arbeitsgruppe Daten teilen oder ihre Operationen synchronisieren müssen, kann dies einen Overhead verursachen, der die optimale Arbeitsgruppengröße beeinflusst. Übermäßige Synchronisation kann dazu führen, dass kleinere Arbeitsgruppen besser abschneiden.
• WebGL-Limits: WebGL setzt Grenzen für die maximale Arbeitsgruppengröße. Sie können diese Limits mit gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_SIZE), gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_INVOCATIONS) und gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_COUNT) abfragen.

Strategien zur Abstimmung der Arbeitsgruppengröße

Angesichts der Komplexität dieser Faktoren ist ein systematischer Ansatz zur Abstimmung der Arbeitsgruppengröße unerlässlich. Hier sind einige Strategien, die Sie anwenden können:

1. Beginnen Sie mit Benchmarking

Der Eckpfeiler jeder Optimierungsanstrengung ist das Benchmarking. Sie benötigen eine zuverlässige Methode, um die Leistung Ihres Compute Shaders mit verschiedenen Arbeitsgruppengrößen zu messen. Dies erfordert die Schaffung einer Testumgebung, in der Sie Ihren Compute Shader wiederholt mit verschiedenen Arbeitsgruppengrößen ausführen und die Ausführungszeit messen können. Ein einfacher Ansatz ist die Verwendung von performance.now(), um die Zeit vor und nach dem Aufruf von gl.dispatchCompute() zu messen.

Beispiel:

const workgroupSizeX = 8;
const workgroupSizeY = 8;
const workgroupSizeZ = 1;

gl.useProgram(computeProgram);
// Uniforms und Texturen setzen

gl.dispatchCompute(width / workgroupSizeX, height / workgroupSizeY, 1);
gl.memoryBarrier(gl.SHADER_STORAGE_BARRIER_BIT);
gl.finish(); // Fertigstellung vor der Zeitmessung sicherstellen

const startTime = performance.now();

for (let i = 0; i < numIterations; ++i) {
    gl.dispatchCompute(width / workgroupSizeX, height / workgroupSizeY, 1);
    gl.memoryBarrier(gl.SHADER_STORAGE_BARRIER_BIT); // Sicherstellen, dass Schreibvorgänge sichtbar sind
    gl.finish();
}

const endTime = performance.now();
const elapsedTime = (endTime - startTime) / numIterations;
console.log(`Arbeitsgruppengröße (${workgroupSizeX}, ${workgroupSizeY}, ${workgroupSizeZ}): ${elapsedTime.toFixed(2)} ms`);

Wichtige Überlegungen zum Benchmarking:

• Aufwärmen (Warm-up): Führen Sie den Compute Shader einige Male aus, bevor Sie mit den Messungen beginnen, damit sich die GPU aufwärmen kann und anfängliche Leistungsschwankungen vermieden werden.
• Mehrere Iterationen: Führen Sie den Compute Shader mehrmals aus und mitteln Sie die Ausführungszeiten, um den Einfluss von Rauschen und Messfehlern zu reduzieren.
• Synchronisation: Verwenden Sie gl.memoryBarrier() und gl.finish(), um sicherzustellen, dass der Compute Shader die Ausführung abgeschlossen hat und alle Schreibvorgänge im Speicher sichtbar sind, bevor Sie die Ausführungszeit messen. Ohne diese spiegelt die gemeldete Zeit möglicherweise nicht die tatsächliche Rechenzeit wider.
• Reproduzierbarkeit: Stellen Sie sicher, dass die Benchmark-Umgebung bei verschiedenen Durchläufen konsistent ist, um die Variabilität der Ergebnisse zu minimieren.

2. Systematische Untersuchung von Arbeitsgruppengrößen

Sobald Sie eine Benchmarking-Umgebung eingerichtet haben, können Sie mit der Untersuchung verschiedener Arbeitsgruppengrößen beginnen. Ein guter Ausgangspunkt ist, Zweierpotenzen für jede Dimension der Arbeitsgruppe auszuprobieren (z. B. 1, 2, 4, 8, 16, 32, 64, ...). Es ist auch wichtig, die von WebGL auferlegten Limits zu berücksichtigen.

Beispiel:

const maxWidthgroupSize = gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_SIZE)[0];
const maxHeightgroupSize = gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_SIZE)[1];
const maxZWorkgroupSize = gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_SIZE)[2];

for (let x = 1; x <= maxWidthgroupSize; x *= 2) {
    for (let y = 1; y <= maxHeightgroupSize; y *= 2) {
        for (let z = 1; z <= maxZWorkgroupSize; z *= 2) {
            if (x * y * z <= gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_INVOCATIONS)) {
              // Setzen Sie x, y, z als Ihre Arbeitsgruppengröße und führen Sie den Benchmark durch.
            }
        }
    }
}

Beachten Sie diese Punkte:

• Nutzung des lokalen Speichers: Wenn Ihr Compute Shader erhebliche Mengen an lokalem Speicher (Shared Memory innerhalb einer Arbeitsgruppe) verwendet, müssen Sie möglicherweise die Arbeitsgruppengröße reduzieren, um den verfügbaren lokalen Speicher nicht zu überschreiten.
• Eigenschaften der Arbeitslast: Die Art Ihrer Arbeitslast kann ebenfalls die optimale Arbeitsgruppengröße beeinflussen. Wenn Ihre Arbeitslast beispielsweise viele Verzweigungen oder bedingte Ausführungen beinhaltet, könnten kleinere Arbeitsgruppen effizienter sein.
• Gesamtzahl der Arbeitselemente: Stellen Sie sicher, dass die Gesamtzahl der Arbeitselemente (gl.dispatchCompute(x, y, z) * workgroupSizeX * workgroupSizeY * workgroupSizeZ) ausreicht, um die GPU vollständig auszulasten. Das Starten von zu wenigen Arbeitselementen kann zu einer Unterauslastung führen.

3. Analysieren Sie die Speicherzugriffsmuster

Wie bereits erwähnt, spielen Speicherzugriffsmuster eine entscheidende Rolle für die Leistung. Idealerweise sollten Arbeitselemente innerhalb einer Arbeitsgruppe auf zusammenhängende Speicherorte zugreifen, um die Speicherbandbreite zu maximieren. Dies wird als gebündelter Speicherzugriff (Coalesced Memory Access) bezeichnet.

Beispiel:

Stellen Sie sich ein Szenario vor, in dem Sie ein 2D-Bild verarbeiten. Wenn jedes Arbeitselement für die Verarbeitung eines einzelnen Pixels verantwortlich ist, wird eine in einem 2D-Gitter (z. B. 8x8) angeordnete Arbeitsgruppe, die auf Pixel in zeilenweiser Reihenfolge zugreift, einen gebündelten Speicherzugriff aufweisen. Im Gegensatz dazu würde der Zugriff auf Pixel in spaltenweiser Reihenfolge zu einem gestreuten Speicherzugriff (Strided Memory Access) führen, der weniger effizient ist.

Techniken zur Verbesserung des Speicherzugriffs:

• Datenstrukturen neu anordnen: Reorganisieren Sie Ihre Datenstrukturen, um gebündelten Speicherzugriff zu fördern.
• Lokalen Speicher verwenden: Kopieren Sie Daten in den lokalen Speicher (Shared Memory innerhalb der Arbeitsgruppe) und führen Sie Berechnungen auf der lokalen Kopie durch. Dies kann die Anzahl der globalen Speicherzugriffe erheblich reduzieren.
• Schrittweite (Stride) optimieren: Wenn ein gestreuter Speicherzugriff unvermeidbar ist, versuchen Sie, die Schrittweite zu minimieren.

4. Minimieren Sie den Synchronisations-Overhead

Synchronisationsmechanismen wie barrier() und atomare Operationen sind notwendig, um die Aktionen von Arbeitselementen innerhalb einer Arbeitsgruppe zu koordinieren. Übermäßige Synchronisation kann jedoch einen erheblichen Overhead verursachen und die Leistung reduzieren.

Techniken zur Reduzierung des Synchronisations-Overheads:

• Abhängigkeiten reduzieren: Strukturieren Sie Ihren Compute-Shader-Code um, um Datenabhängigkeiten zwischen Arbeitselementen zu minimieren.
• Operationen auf Wellenfront-Ebene (Wave-Level) verwenden: Einige GPUs unterstützen Operationen auf Wellenfront-Ebene (auch als Subgroup-Operationen bekannt), die es Arbeitselementen innerhalb einer Welle (einer hardwaredefinierten Gruppe von Arbeitselementen) ermöglichen, Daten ohne explizite Synchronisation zu teilen.
• Sorgfältige Verwendung von atomaren Operationen: Atomare Operationen bieten eine Möglichkeit, atomare Aktualisierungen im Shared Memory durchzuführen. Sie können jedoch teuer sein, insbesondere bei Konflikten um denselben Speicherort. Ziehen Sie alternative Ansätze in Betracht, z. B. die Verwendung von lokalem Speicher zum Sammeln von Ergebnissen und die anschließende Durchführung einer einzigen atomaren Aktualisierung am Ende der Arbeitsgruppe.

5. Adaptive Abstimmung der Arbeitsgruppengröße

Die optimale Arbeitsgruppengröße kann je nach Eingabedaten und aktueller GPU-Last variieren. In einigen Fällen kann es vorteilhaft sein, die Arbeitsgruppengröße basierend auf diesen Faktoren dynamisch anzupassen. Dies wird als adaptive Abstimmung der Arbeitsgruppengröße bezeichnet.

Beispiel:

Wenn Sie Bilder unterschiedlicher Größe verarbeiten, könnten Sie die Arbeitsgruppengröße anpassen, um sicherzustellen, dass die Anzahl der gestarteten Arbeitsgruppen proportional zur Bildgröße ist. Alternativ könnten Sie die GPU-Last überwachen und die Arbeitsgruppengröße reduzieren, wenn die GPU bereits stark ausgelastet ist.

Überlegungen zur Implementierung:

• Overhead: Die adaptive Abstimmung der Arbeitsgruppengröße verursacht einen Overhead durch die Notwendigkeit, die Leistung zu messen und die Arbeitsgruppengröße dynamisch anzupassen. Dieser Overhead muss gegen die potenziellen Leistungssteigerungen abgewogen werden.
• Heuristiken: Die Wahl der Heuristiken zur Anpassung der Arbeitsgruppengröße kann die Leistung erheblich beeinflussen. Sorgfältige Experimente sind erforderlich, um die besten Heuristiken für Ihre spezifische Arbeitslast zu finden.

Praktische Beispiele und Fallstudien

Betrachten wir einige praktische Beispiele, wie die Abstimmung der Arbeitsgruppengröße die Leistung in realen Szenarien beeinflussen kann:

Beispiel 1: Bildfilterung

Stellen Sie sich einen Compute Shader vor, der einen Weichzeichnerfilter auf ein Bild anwendet. Der naive Ansatz könnte darin bestehen, eine kleine Arbeitsgruppengröße (z.B. 1x1) zu verwenden und jedes Arbeitselement ein einzelnes Pixel verarbeiten zu lassen. Dieser Ansatz ist jedoch aufgrund des fehlenden gebündelten Speicherzugriffs sehr ineffizient.

Durch die Erhöhung der Arbeitsgruppengröße auf 8x8 oder 16x16 und die Anordnung der Arbeitsgruppe in einem 2D-Gitter, das an den Bildpixeln ausgerichtet ist, können wir einen gebündelten Speicherzugriff erreichen und die Leistung erheblich verbessern. Darüber hinaus kann das Kopieren der relevanten Pixel-Nachbarschaft in den gemeinsamen lokalen Speicher den Filtervorgang beschleunigen, indem redundante globale Speicherzugriffe reduziert werden.

Beispiel 2: Partikelsimulation

In einer Partikelsimulation wird oft ein Compute Shader verwendet, um die Position und Geschwindigkeit jedes Partikels zu aktualisieren. Die optimale Arbeitsgruppengröße hängt von der Anzahl der Partikel und der Komplexität der Aktualisierungslogik ab. Wenn die Aktualisierungslogik relativ einfach ist, kann eine größere Arbeitsgruppengröße verwendet werden, um mehr Partikel parallel zu verarbeiten. Wenn die Aktualisierungslogik jedoch viele Verzweigungen oder bedingte Ausführungen beinhaltet, könnten kleinere Arbeitsgruppen effizienter sein.

Wenn die Partikel außerdem miteinander interagieren (z. B. durch Kollisionserkennung oder Kraftfelder), können Synchronisationsmechanismen erforderlich sein, um sicherzustellen, dass die Partikelaktualisierungen korrekt durchgeführt werden. Der Overhead dieser Synchronisationsmechanismen muss bei der Wahl der Arbeitsgruppengröße berücksichtigt werden.

Fallstudie: Optimierung eines WebGL Ray Tracers

Ein Projektteam in Berlin, das an einem WebGL-basierten Ray Tracer arbeitete, stellte anfangs eine schlechte Leistung fest. Der Kern ihrer Rendering-Pipeline stützte sich stark auf einen Compute Shader, um die Farbe jedes Pixels basierend auf Strahlschnittpunkten zu berechnen. Nach dem Profiling entdeckten sie, dass die Arbeitsgruppengröße ein erheblicher Engpass war. Sie begannen mit einer Arbeitsgruppengröße von (4, 4, 1), was zu vielen kleinen Arbeitsgruppen und nicht ausgelasteten GPU-Ressourcen führte.

Anschließend experimentierten sie systematisch mit verschiedenen Arbeitsgruppengrößen. Sie fanden heraus, dass eine Arbeitsgruppengröße von (8, 8, 1) die Leistung auf NVIDIA-GPUs erheblich verbesserte, aber auf einigen AMD-GPUs aufgrund der Überschreitung der lokalen Speichergrenzen Probleme verursachte. Um dies zu beheben, implementierten sie eine Auswahl der Arbeitsgruppengröße basierend auf dem erkannten GPU-Hersteller. Die endgültige Implementierung verwendete (8, 8, 1) für NVIDIA und (4, 4, 1) für AMD. Sie optimierten auch ihre Strahl-Objekt-Schnittpunkttests und die Nutzung des Shared Memory in Arbeitsgruppen, was dazu beitrug, den Ray Tracer im Browser nutzbar zu machen. Dies verbesserte die Renderzeit drastisch und machte sie auch über die verschiedenen GPU-Modelle hinweg konsistent.

Best Practices und Empfehlungen

Hier sind einige Best Practices und Empfehlungen für die Abstimmung der Arbeitsgruppengröße in WebGL Compute Shadern:

• Beginnen Sie mit Benchmarking: Erstellen Sie immer zuerst eine Benchmarking-Umgebung, um die Leistung Ihres Compute Shaders mit verschiedenen Arbeitsgruppengrößen zu messen.
• Verstehen Sie die WebGL-Limits: Seien Sie sich der von WebGL auferlegten Grenzen für die maximale Arbeitsgruppengröße und die Gesamtzahl der startbaren Arbeitselemente bewusst.
• Berücksichtigen Sie die GPU-Architektur: Beziehen Sie die Architektur der Ziel-GPU bei der Wahl der Arbeitsgruppengröße mit ein.
• Analysieren Sie die Speicherzugriffsmuster: Streben Sie nach gebündelten Speicherzugriffsmustern, um die Speicherbandbreite zu maximieren.
• Minimieren Sie den Synchronisations-Overhead: Reduzieren Sie Datenabhängigkeiten zwischen Arbeitselementen, um den Bedarf an Synchronisation zu minimieren.
• Nutzen Sie den lokalen Speicher weise: Verwenden Sie lokalen Speicher, um die Anzahl der globalen Speicherzugriffe zu reduzieren.
• Experimentieren Sie systematisch: Untersuchen Sie systematisch verschiedene Arbeitsgruppengrößen und messen Sie deren Auswirkungen auf die Leistung.
• Profilieren Sie Ihren Code: Verwenden Sie Profiling-Tools, um Leistungsengpässe zu identifizieren und Ihren Compute-Shader-Code zu optimieren.
• Testen Sie auf mehreren Geräten: Testen Sie Ihren Compute Shader auf einer Vielzahl von Geräten, um sicherzustellen, dass er auf verschiedenen GPUs und Treibern gut funktioniert.
• Erwägen Sie adaptive Abstimmung: Prüfen Sie die Möglichkeit, die Arbeitsgruppengröße dynamisch an die Eingabedaten und die GPU-Last anzupassen.
• Dokumentieren Sie Ihre Ergebnisse: Dokumentieren Sie die von Ihnen getesteten Arbeitsgruppengrößen und die erzielten Leistungsergebnisse. Dies wird Ihnen helfen, in Zukunft fundierte Entscheidungen über die Abstimmung der Arbeitsgruppengröße zu treffen.

Fazit

Die Abstimmung der Arbeitsgruppengröße ist ein entscheidender Aspekt bei der Leistungsoptimierung von WebGL Compute Shadern. Durch das Verständnis der Faktoren, die die optimale Arbeitsgruppengröße beeinflussen, und durch einen systematischen Ansatz zur Abstimmung können Sie das volle Potenzial der GPU ausschöpfen und erhebliche Leistungssteigerungen für Ihre rechenintensiven Webanwendungen erzielen.

Denken Sie daran, dass die optimale Arbeitsgruppengröße stark von der spezifischen Arbeitslast, der Ziel-GPU-Architektur und den Speicherzugriffsmustern Ihres Compute Shaders abhängt. Daher sind sorgfältige Experimente und Profiling unerlässlich, um die beste Arbeitsgruppengröße für Ihre Anwendung zu finden. Indem Sie die in diesem Artikel beschriebenen Best Practices und Empfehlungen befolgen, können Sie die Leistung Ihrer WebGL Compute Shader maximieren und eine flüssigere, reaktionsschnellere Benutzererfahrung bieten.

Während Sie die Welt der WebGL Compute Shader weiter erkunden, denken Sie daran, dass die hier besprochenen Techniken nicht nur theoretische Konzepte sind. Es sind praktische Werkzeuge, die Sie verwenden können, um reale Probleme zu lösen und innovative Webanwendungen zu erstellen. Also, tauchen Sie ein, experimentieren Sie und entdecken Sie die Kraft optimierter Compute Shader!